gh-158446: Reject float format precision near INT_MAX - #158474

…) (#158478)

gh-158446: Reject float format precision near INT_MAX (GH-158474)

Formatting a float or complex with a precision within about 1000 of
INT_MAX could crash or produce incorrect output.
PyOS_double_to_string() now raises ValueError("precision too big") for
such precisions, as the format string parsers already do for
precisions above INT_MAX.

The limit applies regardless of presentation type or value, so a few
calls that previously succeeded (inf, nan, or 'g' with such a
precision) now raise as well.
(cherry picked from commit b7b4f3e)

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>

…) (#158476)

gh-158446: Reject float format precision near INT_MAX (GH-158474)

Formatting a float or complex with a precision within about 1000 of
INT_MAX could crash or produce incorrect output.
PyOS_double_to_string() now raises ValueError("precision too big") for
such precisions, as the format string parsers already do for
precisions above INT_MAX.

The limit applies regardless of presentation type or value, so a few
calls that previously succeeded (inf, nan, or 'g' with such a
precision) now raise as well.
(cherry picked from commit b7b4f3e)

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>

…) (#158477)

gh-158446: Reject float format precision near INT_MAX (GH-158474)

Formatting a float or complex with a precision within about 1000 of
INT_MAX could crash or produce incorrect output.
PyOS_double_to_string() now raises ValueError("precision too big") for
such precisions, as the format string parsers already do for
precisions above INT_MAX.

The limit applies regardless of presentation type or value, so a few
calls that previously succeeded (inf, nan, or 'g' with such a
precision) now raise as well.
(cherry picked from commit b7b4f3e)

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>

…) (#158479)

* gh-158446: Reject float format precision near INT_MAX (GH-158474)

Formatting a float or complex with a precision within about 1000 of
INT_MAX could crash or produce incorrect output.
PyOS_double_to_string() now raises ValueError("precision too big") for
such precisions, as the format string parsers already do for
precisions above INT_MAX.

The limit applies regardless of presentation type or value, so a few
calls that previously succeeded (inf, nan, or 'g' with such a
precision) now raise as well.
(cherry picked from commit b7b4f3e)

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>

* gh-158446: Fix the new test_format test on 3.12

test_format.py does not import import_module on this branch.  Import
INT_MAX from _testcapi directly, as the neighboring test does.

---------

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>

…) (#158482)

Formatting a float or complex with a precision within about 1000 of
INT_MAX could crash or produce incorrect output.
PyOS_double_to_string() now raises ValueError("precision too big") for
such precisions, as the format string parsers already do for
precisions above INT_MAX.

The limit applies regardless of presentation type or value, so a few
calls that previously succeeded (inf, nan, or 'g' with such a
precision) now raise as well.
(cherry picked from commit b7b4f3e)

…) (#158480)

* gh-158446: Reject float format precision near INT_MAX (GH-158474)

Formatting a float or complex with a precision within about 1000 of
INT_MAX could crash or produce incorrect output.
PyOS_double_to_string() now raises ValueError("precision too big") for
such precisions, as the format string parsers already do for
precisions above INT_MAX.

The limit applies regardless of presentation type or value, so a few
calls that previously succeeded (inf, nan, or 'g' with such a
precision) now raise as well.
(cherry picked from commit b7b4f3e)

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>

* gh-158446: Fix the new test_format test on 3.11

test_format.py does not import import_module on this branch.  Import
INT_MAX from _testcapi directly, as the neighboring test does.

---------

Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>